High Performance Computing with R @ UC Santa Barbara

• What is high performance computing?
• Overview of UCSB resources
• Accessing pod and knot
• Running jobs
• Some specifics for R
• An example
• Give it a try
• Demo

Why and when to use HPC?

• Designed for when computational problems are either too large, take too long, and/or require large file storage for standard computers

• When HPC might not be your solution:

  • There’s lots of interaction with the program, and single runs (You need a really powerful desktop)
  • You need 1,000 nodes, but only once every 3 months (Cloud resources may be your solution)
  • You need 1,000 nodes, all the time (You need your own cluster)
  • You work with sensitive data

• Serial vs. Parallel computing
• Serial:
  • one core on one node at a time
• Parallel:
  • many tasks can be performed at once that are independent
  • or tasks can occur at the same time when 'boundry conditions' match up

• Center for Scientific Computing
  • pod cluster (2018), knot cluster (2011), braid (condo clusters)
• Letters and Science Information Technology
  • Aristotle cloud cluster
    • ideal for teaching e.g., Jypter notebooks
    • presistent internet connection collected data
• Extreme Science and Engineering Discovery Environment (XSEDE)
• West coast consumer wide consumer grade GPU cluster (machine learning)
  • Nautilus cluster
• Triton Shared Computing Cluster (TSCC) at San Diego Supercomputing Center (SDSC)

• accounts
  Request access: http://csc.cnsi.ucsb.edu/acct

• Xsede: NSF sponsored service organization that provides access to computing resources.

Campus Champion (Sharon Solis): Represents XSEDE on the campus

• pwd
• cd
• ls
• mkdir
• mv
• rm
• nano (link to SC here) .bash_history (up arrow, stores 1000 lines) more .bash_history | grep qsub

• scheduler
  • fair share model
• queues showq

• versions
• libraries

1. login to cluster
2. transfer input files
3. create a submission script
4. submit your job and check the status
5. scheduler runs computation on compute nodes
6. examine and transfer output files

1. login to cluster

ssh username@pod.cnsi.ucsb.edu

1. transfer input files
   

scp file.txt user@pod.cnsi.ucsb.edu:file_copy.txt

Lets also make a quick R code to run

echo “data <- data.frame(x=seq(1:10),y=seq(1:10)); write.csv(data,”testcsv.csv”,row.names=F)“ > myscript.R

1. create a submission script
   

nano submit.job
#!/bin/bash -l
#Serial (1 core on one node) job...
#SBATCH --nodes=1 --ntasks-per-node=1

cd $SLURM_SUBMIT_DIR
module load R
Rscript myscript.R

1. submit your job and check the status
   

sbatch submit.job
qstat -u mdono

1. wait…

   via GIPHY

1. transfer output files
   

scp file.txt user@pod.cnsi.ucsb.edu: file_copy.txt

• Remote login: UCSB VPN
  
• Try a small version of your code on your computer first to make sure it runs from beginning to end.
  
• Be explicit about location of input and output files
  
• Please include in your papers! “We acknowledge support from the Center for Scientific Computing from the CNSI, MRL: an NSF MRSEC (DMR-1720256) and NSF CNS-1725797.”